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FILES-11 ON-DISK STHUCTUHE 



1.0 Scope 

This document: is a specification of the 

structure_ that is used by Files-11. Files-11 is a genlrll 
purpose file structure which is intended to be the standard 
file structure for all mediua to large PDP-11 systems. 
Small systems such as HT-11 have been soecifica** ly excluded 
because the complexity of Files-11 would impose too great e 
burden on their simplicity and small size. 



This document describes structure level 1 of Files-11, 
also referred to as .ODS-1 (on-disk structure version 1) 
This is the only version of Files-11 which is implemented on 
any of the supporting operating systems. A proposed 
structure level- 2 (ODS-2) exists but has not been 

implemented anywhere. 



2.0 Medium 

Files-11 is a structure which is imposed on a medium 
Tnat medium must have certain properties, which are 
aescribed in the following section. Generally speaking, 
block addressable storage devices such as disks and Dectape 
are suitable for Files-11; hence Files-11 structured media 
are generically referred to as disks. 



2.1 Volume 

* 

The basic medium that carries a Files-11 structure is 
referred to as a xalilSLS. A volume (also often referred to 
as a i mlt ) is defined as an ordered set of I o g 1 e a 1 bTocks. 
A logical block is an array of 512 3-bit bytes. The logical 
blocks in a volume are consecutively numbered from 0 to n-1 
where the volume contains n logical blocks. The number 
assigned to a logical block is called its logical. block 
aufflbgr .i ^ or L SM • Files-11 is theoretically capable of 

describing volumes up to 2**32 blocks in size. In practice 
a volume should be at least 100 blocks in size to be useful; 
current implementations of Files-11 will handle volumes up 
to 2**24 blocks. 

The logical blocks of a volume must be randomly 
addressable. The volume must also allow transfers of any 
length up to 65k bytes, in multiples of four bytes. When a 
transfer is longer than 512 bytes, consecutively numbered 
logical blocks are transfered until the byte count is 
satisfied. in other words, the volume can be viewed as a 
partitioned array of bytes. It must allow reads and writes 
of arrays of any length less than 65k b.ytes, provided that 
tney start on a logical block boundary and that the length 
IS a multiple of four bytes. When only part of a block is 
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written, the contents of the remainder of that logical block 
will be undefined. 



2.2 VoluaeSets 

A V o 1 ume set is a collection of related units that are 
normally treatea as one logical device in the usual 
operating system concept. Each unit contains its own 
Files-11 structure; however, files on the various units in 
a volume set may be referenced with a relative volume 
number . which uniquely determines which unit in the set the 
file is located on. Other sections in this specification 
will make occasional reference to volume sets and relative 
volume numbers where hooks for their implementation exist. 
Since volume sets have not bean implemented as yet, however, 
no complete specification is provided here. 



3.0 Files 



Any data in a volume or volume set that is of any 
interest (i.e., all blocks not available for allocation) is 
contained in a f lie . A file is an ordered set of v i r.t,yg,l 
nlQcks ■ where a virtual block is an array of 512 8 bit 
bytes. The virtual blocks of a file are consecutively 
numbered from 1 to n, where n blocks have been allocated to 
the file. The number assigned to a virtual block -is called 
(obviously) its virtual block number , or V3.N. . Each virtual 
block is mapped to a unique logical block in the volume set 
'by Files-11. Virtual blocks may be processed in the same 
manner as logical blocks. Any array of bytes less than 65k 
in length may be read or written, provided that the transfer 
starts on a virtual block boundary and that its length is a 
multiple of four. 



3.1 File ID 

Each file in a volume set is uniquely identified by a 
File TD . A File ID is a binary value consisting of 48 bits 
(3 PDF-n words). It is supplied by the file system -when 
the f: le is created, and must be supplied by the user 
whenever he wishes to reference a particular file. 

The three words of the File ,ID are used as follows: 

Word 1 File Number 

Locates the fils within a particular unit of the 
volume set. File numbers must l.ie in the range l 
through 65535 . The sat of fils number's on a unit 
is moderately (but not totally) dense; at any 
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Word 2 



instsnt in tias z. fils nua'osr unicusly 
one file within that unit. 

File Sequence Number 



identifies 



Word 5 



Identifies thecurrent use of an individual fils 
number on a unit. File numbers are re-used; when 
a fij.e is deleted its file number bsccaes 
available for future use for soae other fils. 
Each tiae a fils number is re-used, a different 
file sequence number is assigned to distinguish 
the uses of that file number. The file sequence 
number is essential since it is perfectly legal 
for users to remember and attempt to use a File ID 
long aft^r that file has been deleted. 

Relative Volume Number 



Identifies which unit of a volume set the file is 
located on. Volume sets are at present . not 
implemented; the only legal value for ' the 
^®ls.iive volume number in any context is zero. 



3.2 



File Header 



» Each file on a Files-11 volume is described by a f j i o 
Ji a d g n • The file header is a block that contains all the 
information necessary to access the file. It is not part of 
the file; rather, it is contained in the volume's index 

The 



iile. (The index file is described in section 5.1). 



header block is organized into 
first three are variable in size. 



four areas, of which the 



3 . 2.1 



Header Area 



3 . 2.2 



The information in the header area permits the 
file system to verify that this block is in fact a 
file header and, in particular, is. the header 
being sought by the user. It contains the file 
number and file sequence number of the file, as 
well as its ownership and protection codes. This 
area also contains offsets to the other areas of 
the file header, thus defining their size. 
Finally, the header area contains a user attribute 
area, which may be used by the user to store a 
limited amount of data describing the file. 

Ident .Area 



The ident area of a file header contains 
identification and accounting data about the file. 
Stored here are the primary name of the file, its 




U) 



FIL£S-11 0^^-DISK STHUCTUHE 



P'AGE 5 



creation date and tine, revision count, date, and 
tine, and expiration date. 

.2.3 Map Area 

Tne nap area describes the napping of virtual 
blocks of the file to the logical blocks of the 
volune. The napping data consists of a list of 
r a t r 1 e V a 1 pointers . Each retrieval pointer 

describes one logically contiguous segnent of the 
file. The nap area also contains the linkage to 
the next extension header of the file, if such 
exists . 

.2.4 • End Checksum 

The last two bytes of the file header contain a 16 
bit additive checksum of the remaining 255 words 
of the file header. The checksum is used to help 
verify that the block is in fact a file header. 



5.3 Extension Headers 

Since the ' file header is of fixed size, it is 
inevitable that for some files the napping information will 
not fit in the allocated space. A file with a large amount 
of mapping data is therefore represented with a chain of 
» file headers. Each header maps a consecutive set of virtual 

blocks; the extension linkage in the map area links the 
headers together in order of ascending virtual block 
numbers . 

Multiple headers are' also needed for files that span 
units in a volume set. A header may only map logical blocks 
located on its unit; . therefore a multi-volume file is 
represented by headers on all units that contain portions of 
that file. 



3.4' File Header - Detailed Description 

This section describes in detail the items contained in 
the file header. Each item is identified by a symbol which 
represents the offset address of that item within its area, 
in the file header. Any item may be located in the file 
header by locating the area to which it belongs and then 
adding the value of its offset address. Users who concern 
i^hem selves with the contents of file headers are strongly 
urged to use the offset symbols. The symbols may be defined 
in assembly language programs by calling . and invoking the 
macro FHD0F$, which may be found in the macro library of any 
system that supports Files-11. Alternatively, one may find 
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tiia aacro in the file F11MAC.MAC, 
the author. 



which a a y he 



obtained fron 



Header .Area Description 



The header area of t he file header al w a ys starts at 
byte 0. It contains the basic information needed for 
cneoking the validity of accesses to the file. 

H.IDOF 1 Byte Ident Area Offset 

This byte contains the number of 16 bit words 
between the start of the file header and the start 
of the ident area. It defines the location of the 
area and the size of the header area. 

3. ^.1.2 H.iMPOF 1 Byte Map Area Offset 



This byte contains the number of 16 bit words 
between the start of the file header and the start 
of the map area. It defines the location of the 
aap area and, together with H.IDOF, the size of 
the ident area . 

h.^.1.3 H.FNUM' 2 Bytes File Num.ber 

word contains the file number of the file. 

3. 4*1. 4 H.fSaQ 2 Bytes File Sequence Number 

This word contains the file sequence number of the 
file. 

3. 4. 1.5 H.rLEV 2 Bytes File Structure Level 

Tne file structure level is used to identify 
different versions of Files-ll as they affect the 
structure of the file -header. This permits 
upwards compatibility of file structures as 
Files-11 evolves, in that the structure level word 
identifies the version of Files-11 that created 
this particular file. This document describes 
version 1 of Files-11; the only legal contents 
for H.FLEV is 401 octal. 



3* 4. 1.6 H.FOWN 
H.PROG 
H . PROJ 



2 Bytes File Owner OIC 

H.FOWN+0 Programmer (Member) Number 

H.FOWN+1 Project (Group) Number 



This word contains the binary user identification 
code (UIC) of the owner of the file. The file 
owner is usually (but not necessarily) the creator 
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of the file. 

3. 4. 1.7 H.FPHO 2 Bytes File Protection Code 

This word controls whet access all users in the 
systea may have to the file. Accessors of a file 
are categorized according to the relationship 
between the UIC of the accessor and the UIC of the 
owner of the file. Each category is controlled by 
a four bit field in the protection word. The 
category of the accessor is selected as follows: 

System Bits 0-3 

The accessor is subject to system 
protection if the project number of the 
UIC under which he is running is 10 
octal or less. 

Owner Bits 4 - 7 

The accessor is subject to owner 
protection if the UIC under which he is 
running exactly matches the file owner 
UIC. 

Group Bits 8-1,1 . 

The accessor is subject to group 
protection if the project number of his 
UIC matches the project number of the 
file owner UIC. 

World Bits 12 - 15 

The accessor is subject to world 
protection if he does not fit into any 
of the above categories. 

Four types of access intents are defined in 
Files-11: read, write, extend, and delete. Each 

four bit field in the protection word is bit 
encoded to permit or deny any combination of the 
four types of access to that category of 
accessors. Setting a bit denies that type of 
access to that category. The bits are defined as 
follows (these values apply to a right- justif ied 
protection field): 

FP.RDV Deny read access 

FP.WHV Deny write access 

FP.EXT Deny extend access 

FP.DEL Deny delete access 
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Wnen a user attempts to access i file, protection 
checks^ are performed in ail the categories to 
which he is eligible, in the order system - owner 
~ 3 ^'oup - world. The user is granted access to 
the file if any of the categories to which he is 
eligible grants him access. 



.4.1.6 



H.FCHA 
H. UCHA 
H.SCHA 



2 Bytes File Characteristics 
H.FCHA+0 User Controlled Char. 
H.FCHA+1 System Controlled Char. 



The user controlled characteristics byte contains 
the following flag bits: 



Set if the file is logically contiguous : 
i.e., if for all virtual blocks in the 
file, virtual block i maps to logical 
block k+i on one unit for some constant 
k. This bit may be implicitly set or 
cleared by file system operations that 
allocate space to the file; the user 
may only clear it e.xplicitly. 



Set if the file is deaccess— locked. 
This bit is used as a flag warning that 
the file was not- properly closed and may 
contain inconsistent data.- Access to 
the file is denied if this bit is set. 



The system 
contains the 



controlled characteristics 
following flag bits: 



byte 



SC.MDL 



SC. BAD 



4.1.S H.UFAT 



Set if the file is marked for delete. 
If this bit is set, further accesses to 
the file are denied, and the file will 
bs physically deleted when no users are 
accessing it. 

Set if there is a bad data block in the 
file. This bit is as yet unimplemented. 
It is intended for dynamic bad block 
handling . 

32 Bytes User Attribute Area 



This area is intended for the storage of a limited 
quantity of "user file attributes", i.e., any data 
the user deems useful for processing the file that 
is not part of the file itself. An example of^the 
use of the user attribute area is oresented in 
section 6.1 (FCS File Format). 
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3.4.1.10 S.HDHD 48 Bytes Size of Header Area 

This syabol represents the total size of the 
header area containing all of the above entries. 

3.4,2 Ident Area Description 

The ident area of the file header begins at the word 
indicated by H.IDOF. It contains identification and 

accounting data about the file. 

3.4.2. 1 I.FNAM 6 Bytes File Name 

These three words contain the name of the file, 
packed three Radix-50 characters to the word. 
This name usually, but not necessarily, 

corresponds to the name of the file's primary 
directory entry: 

3. 4. 2. 2 I.FTYP 2 Bytes File Type 

This word contains the type of the file in the 
form of three Radix-50 characters. 

3'.4.2.3 I.FVER 2 Bytes Version Number 

This word contains the version number of the file 
in binary form. 

3. 4. 2. 4 I.RVNO 2 Bytes Revision Number 

This word contains the revision count of the file. 
The revision count is the number of times the file 
has been accessed for write. 

3. 4. 2. 5 I.RVDT 7 Bytes Revision Date 

The revision date is the date on which the file 
was last deaccessed after being accessed for 
write. It is stored in ASCII in the form 
"DDMMMYY", where DD is two digits representing the 
day of the month, MMM is three characters 

representing the month, and YY is the last two 
digits of the year. 

3. 4. 2. 6 ■ I.RVTI 6 Bytes Revision Time 

The revision time is the time of day on which the 
file was last deaccessed after being accessed for 
write. It is stored in ASCII in the format 
"HHMMSS”, where HH is the hour, MM is the minute, 
and S3 is the second. 
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3. 4. 2. 7 I.CHDT 7 Bytes Creation Dat'e 

These seven bytes contain the date on which the 
file was created. The format is the same as chat 
oftherevisiondateabove. 

5. ^.2. 3 I.CfiTI 6 Bytes Creation Time 

These six bytes contain the time of day at which 
the file was created. The format is the same as 
that of the revision time above. 

3. ^.2. 9 I.EXDT 7 Bytes Expiration Date 

These seven bytes contain the date on which th 
f^e becomes eligible to be deleted. The forma 
is the same as that of the revision and creation 
dates above. 

0.4.2. 1G - 1 Byte (unused) 

This unused byte is present to round up the size 
if the ident area to a word boundary. 

5.4.2.11 S.IDHD 46 Bytes Size of Ident Area 

This symbol represents the size of the ident 'area 
“ containing all of the -above ejitries. 

3-4.3 Map Area Description 

The map area of the file header starts at the word 
indicated by H.MPOF. It contains the information necessary 
to map the virtual blocks of the file to the logical blocks 
of the volume. 

3.4.3. 1 M . ESQN 1 Byte Extension Segment Number 

This byte contains the value n, where this header 
is the n+lth header of the file; i.e., headers of 
a file are numbered sequentially starting with 0. 

3. 4. 3. 2 M.ERVN 1 Byte Extension Relative Volume No. 

This byte contains the relative volume number of 
the unit in the volume set that contains the next 
sequential extension header for this file. If 
there is no extension header, or if the extension 
header is located on the same unit as this header, 
this byte contains 0. 



Ct (D 




Lxl La> Ui Lxi U3 




.4.3.5 M.EFNU 2 Bytes Extension File Number 

This word contains the file number of the next 
sequential extension' header for this file. If 
there is no extension header, this word contains 

0 . 

.4.5.4 M.EFSQ 2 Bytes Extension Fils Sequence 'lumber 

This word contains the fils sequence number of the 
next sequential extension header for this file. 
If there is -no extension header, this word 
contains 0 . 

.4.3.5 M.CTSZ 1 Byte Block Count Field Size 

This byte contains a count of the number of bytes 
used to represent the count field in the retrieval 
pointers in the map area. The retrieval pointer 
format is described in section 3. 4 . 3. 9 below. 

.4.3.6 M.LBSZ 1 Byte LBN Field Size 

This byte contains a count of the number of bytes 
used to represent the logical block number field 
in the retrieval pointers in the - map area. The 
contents of M.CTSZ and M.LBSZ must add up to an 
even number. 

% 

.4.3.7 M.USE 1 Byte Map Words In Use 

This byte contains a count of the number of words 
in the map area that are presently occupied by 
retrieval pointers. 

.4.3.8 M.MAX 1 Byte Map Words Available 

This byte contains the total number of words 
available for retrieval pointers in the map area. 

3.4. 3 . 9 M.RTRV variable Retrieval Pointers 

This area contains the retrieval pointers that 
actually map the virtual blocks of the file to the 
logical blocks of the volume. Each retrieval 
pointer describes a consecutively numbered group 
of logical blocks which is part of the file. The 
count field contains the binary value n to 
represent a group of n +1 logical blocks. The 
logical block number field contains the logical 
block number of the first logical block in the 
group. Thus each retrieval pointer maps virtual 
blocks j through j+n into logical blocks k through 
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k+n, respectively, where j is the total nuaber 
plus one of virtual blocks represented by all 
preceding ' retrieval pointers in this and all 
preceding headers of the file, n is the- value 
oontained in the count field, and k is the value 
contained in the logical block nuaber field. 

Although the data in the aap area provides for 
arbitrarily extensibl'e retrieval pointer foraats, 
Fiies-11 has defined only three. Of these, only 
the first is currently iapleaented ; the other two 
are presented- out of historical interest and 
because they may be resurrected in the future. 

Format 1: M.CTSZ = 1 
M.LBSZ = 3 

The total retrieval pointer length is 
four bytes. Byte 1 contains the high 



order bits of 


the 24 


bit LBN. 


Byte 2 


contains the 


count 


field, and 


bytes 3 


and 4 contain 
LBN. 

1 1 


the low 


1 6 bits 

1 


of the 


! Count 1 


High 


1 

P 


. . 


! Low Order 

\ 


■ LBN 


1 

1 

^ 1 





Format 2: M.CTSZ = 2 
M.LBSZ = 2 

The total retrieval pointer length is 
four bytes. The first word contains a 
16 bit count field and the second word 
contains a 16 bit LBN field. 



Count 



LBN 



Format 3: M.CTSZ s 2 
M.LBSZ =4 

The total retrieval pointer length is 
six, bytes. The first word contains a 16 
bit count field and the second and third 
words contain a 32 bit LBN field. 
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Count 


. — — j 




High 




1 -- 




-- 1 




Low 





. 4 . 3.10 S.MPHD 10 Bytes Size of Map Area 

This symbol represents the size of the map area, 
not including the space used for the retrieval 
pointers . 



3*^.4 End Checksum Description 

The header check sum occupies the last two bytes of the 
file header. It is verified every time a header is read, 
and is recomputed every time a header is written. 



3.4.4. 1 



H . CKSM 2 Bytes Block Checksum 



This word is a simple additive checksum of all 
other words in the block.. It is computed by the 
following PDP-11 routine or its equivalent: 



10 $: 



MOV Header-address , RO 

CLH R1 

MOV #255., R2 

ADD (H0)+,R1 

SOB R2,10$ 

MOV R1,(R0) 



A 
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3 . ^ . A. 


File Header Layout 




Header 


Area 

1 1 




K .MFC? 


1 — — — — — — — — — j — — — — — — — — — 

! Map Area Offset i Ident Area Offset 

1 I 


j H.IDOF 

\ 




1 FileNuaber 

» 


\ H.FNUM 

1 




! File Sequence Nuaber 


! K.FSEQ 

1 




i File Structure Level 


i H.FLSV 

_ ! H P n U M 


H . PRGJ 


1 File Owner UIC 

1 


••1 n • r u n 4 1 

i H.PROG 

^ 1 




1 File Protection 


i H.FPRO 

_ • u cry a 


H.SCHA 


'! System Char. 1 User Char. 


• 1 n • • u n it 

! H.UCKA 

^ J 




1 

1 


i H.UFAT 

1 
1 




1 

I 

I User Attribute Area 

1 

1 


1 

1 

1 

1 

1 

1 

1 




1 


1 

1 

1 

-! S.HDHD 



Ident Area 



I •- 


File Name 


! I.FNAM 

1 

1 

1 

^ ^ 1 

1 

1 




File Type 


! I.FTY? 

1 




Version Number 


! I.FVER 

. «....«> ' 




Revision Number 


1 I.RVNO 


1 -- 


Revision Date 
1 


1 I.RVDT 

\ 

1 

-- I 

1 

1 

^ ^ 1 



i.RVTI 
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1 

1 

1 ^ ^ 

1 

1 

1 


1 

Revision Tinse -- i 

1 

1 




I . CRDT 


1 -mm mm ^ mm mm 

\ 

1 

1 


t i 






1 

1 ^ ^ 

1 

J 

1 

1 

1 

J 


1 

1 

1 

Creation Dare 1 

1 

1 






1 

1 

1 

1 ^ ^ 

1 

1 

1 

1 

1 

1 


1 

1 

Creation Tiais i 

1 

1 


I .CRTI 




1 

1 

1 

1 ^ ^ 

1 

1 

1 ^ ^ 

1 

1 

J 


1 

I 

Expire tion Date [ 

1 

1 

1 


I . E.XDT 




i 

1 

1 

1 


(not used) 1 1 


c Town 








O • Xu £IU 


Map Area 


1 


- 

! J 




M. EHVN 


, , , 

1 Extension RVN ! Ext. Seg. Num. 1 

• 1 1 


M . ESQf. 




i 

J 

1 

1 


Extension File Number ! 

1 


M. EFNU 




i ^ 

1 
1 
1 


Extension File Seq. Num. 1 


M. EFSQ 


M.LBSZ 


1 LBN 
1 


Field Size ! Count Field Size j 


M.CTSZ 


M.MAX 


1 

1 Map 
» 


Words Avail. ! Map Words in Use i 

_ 1 1 


M.USE 

c Mown 




1 

1 

1 

1 


1 

1 

1 


o . Kr ri JJ 
M.RTRV 




1 

1 

1 

1 

I 

1 

1 

1 

1 

1 

1 


1 

Retrieval Pointers ! 

\ 

1 

1 

1 

— I 






1 

1 

1 

1 — — — — — 


File Header Checksum ! 

1 


H . CKSM 
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^.0 Directories 

Files-11 provides directories to allow the organization 
of files in a meaningful way. While the File ID is 
sufficient to locate a file uniquely on a volume set, it is 
hardly mnemonic. Directories are files whose sole function 
is to associate file name strings with File ID's. 



Directory Heirarchies 

Since directories are files with no special attributes, 
directories may list files that are in turn directories. 
Thus the user may construct directory .heirarchies of 
arbitrary depth and complexity to structure his files as he 
pleases . 



^•I-I User File Directories 

Current implementations of Files-11 all support a two 
level directory heirarchy which is tied in with the user 
identification mechanism of the operating system. Each UIC 
is associated with a user file directory (UFD). References 
to files that do not specify a directory are generally 
defaulted to the UFD associated with the user's UIC. All 
UfD's are listed in the volume's MFD under a file name 
constructed from the UIC. A UIC of Cn,m] associates with a 
directory name of '*nnnmmm. DIR ; 1 " , where nnn and mmm are n 
and m padded out to three digits each with leading zeroes. 
Note that all number conversions are done in octal. 

Two points should be noted here. The UFD structure 
described here is not intrinsically part of the Files-il 
on-disk structure; rather, it is a convenient cataloging 
system applied by various operating systems. Also, there is 
no hard and fast relationship between the owner UIC of a 
file and the UFD in which it is listed. Generally, they 
will correspond, but not necessarily. 



4.2 Directory Structure 

A directory is a file consisting of 16 byte records. 
It is structured as an FCS fixed length record file, with no 
carriage control attributes (see section 6 for a description 
of FCS files). Each record is a directory entry. The 
entries are not required to be ordered, or densely packed, 
nor do they have any other relationship to each other, 
except that no two entries in one directory may contain the 
same name, type, and version. Each entry contains the 
following : 
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File ID The three word binary File ID o’f the file that 
this directory entry represents. If the file 
number portion of the File ID field is zero, then 
this record is empty and may be used for a new 
directory entry. 



Name The name of the file may be up to S characters. 

It is stored as three words, each containing three 
Radix- 50 packed characters. 



Type The type of the file (also historically referred 

to as the ■ extension) may be up to three 
characters. It is stored as one word of Radix-50 
packed characters. 



Version The version number'of the fils is stored in binary 
in one word. 



1 -- 


File ID 










\ 


Name 


1 


i Type 1 


1 Version, 1 



‘*.5 Directory Protection 

Since directories are files with no special 

characteristics, they may be accessed like all other files, 
and are subject to the same protection mechanism. However, 
implementations of Files-11 support three special functions 
for^the management of directories, namely FIND, REMOVE, and 
ENTER. A user performing such- a directory operation must 
have the following privileges to be allowed the various 
functions; 

FIND: READ 

REMOVE: READ, WRITE 

ENTER: READ, WRITE, EXTEND 
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5.0 Known Files 

Clearly any file systen must maintain some data 
structure on the medium which is used to control the file 
organization . In Files-11 this data is kept in five files. 
These files are ■ created when a new volume is initialized. 
They are unique in that their File ID • s are known constants. 
Tnese five files have the following uses: 

File ID 1,1,0 is the index file . The index file is the 
root of the entire Files-11 structure. It contains the 
volume's bootstrap block- and the home blook, which is used 
to identify the volume and locate th-e rest of the file 
structure. The index file also contains all of the file 
headers for the volume, and a bitmap to control the 
allocation offile headers. 

File ID 2,2,0 is the storage b i tma g f j 1 . it is used 
to control the allocation of logical blocks on the volume. 

File ID 5»3,0 is the bad block f ile . It is a file 
containing all of the known bad blocks on the volume. 

File ID 4,4,0 is the volume master file directory (or 
MFD ) . It forms the root of the volume's directory 
structure. The MFD lists the five known files, all first 
level .user directories, and whatever other files the user 
chooses to enter. • . » 

File ID 5,5,0 is the system core image file . Its use 
is operating system dependent; its basic purpose is to 
provide a file of known File ID for the use of the operating 
system . 



5.1 Index File 

The index file is File ID 1,1,0. It is listed in the 
MFD as INDSXF . SYS ; 1 . The index file is the root of the 
Files-11 structure in that it provides the means for 
identification and initial access to a Files-11 volume, and 
contains the access data for all files on the volume 
(including itself). 



5.1.1 Bootstrap Block 

Virtual block 1 of the index file is the volume's boot 
block . It is always mapped to logical block 0 of the 
volume. If the volume is the sys.tem device of an operating 
system, the boot block contains an operating system 
dependent program which reads the operating system into 
memory when the boot block is read and executed by a 
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maohins's hard wars bootstrap. If" ths vol i-ijn s is not a systsis 
devics, the boot block contains a saall prograa that outputs 
a message on the system console to inform ths operator to 
that effect. 



5 . 1.2 Home Block 

Virtual block 2 of the index file is the volume's home 
P ^ P ^ • Ths logical block containing the home block is the 
first good block on the volume out of the sequence 1, 256, 

512, 76b, 1024, 1260, 256»n. The purpose of ths home 

block is to identify the volume as Files-11, establish ths 
specific identity of the volume, and serve as the ground 
zero entry point into the^volume's file structure. The home 
block is recognized as a home block by ths presence of 
checksums in known places and by the presence of predictable 
values in certain locations. 

Items contained in ths home block are identified by 
symbolic offsets in the same manner as items in the fils 
header. Ths symbols may be defined in assembly language 
programs by calling and invoking the macro HMB0F$, which may 
be found in ths macro library of any system that supports 
Files-11. Alternatively, one may find the macro in the file 
F11MAC.MAC, which is available from the author. 

5. 1.2.1 H.1 3i2 Z 2 By tes Index File-Bitmap Size 

This 16 bit word contains ths number of blocks 
that make up the index file bitmap. (Ths index 
file bitmap is discussed in section 5.1.3.) This 
value, must be non-zero for a valid home block. 

5. 1.2. 2 H.IBL3 4 Bytes Index File Bitmap LBN 

This double word . contains the starting logical 
block address of the index file bitmap. Once the 
home block of a volume has been found, it is this 
value that provides access to the rest 'of the 
index file and to the volume. Ths LBN is stored 
with the high order in the first 16 bits, followed 
by the low order portion. This value must be 
non-zero for a valid home block. 

5. 1.2. 3 H . FMAX 2 Bytes Maximum Number of Files 

This word contains the maximum number of files 
that may be present on the volume at any time. 
This value must be . non-zero for a valid home 
block. 
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3. 1 .2.5 
5 . 1 . 2 . 6 



5. 1 .2.7 



5 . 1 . 2 . 8 

5.1 .2.9 

5 . 1 . 2.10 



H.SSCL 2 Byt$s Storage Bita-ap Cluster Factor 

This word contains the clusterfactor used in the 
storage bitaap file. The cluster factor is the 
number of blocks represented by each bit in the 
storage bitmap. Volume clustering is not 

implemented at present; the only legal value for 
this item is 1 . 

H.DVTY 2 Bytes Disk Device Type 

This word is an index identifying the type of disk 
that contains this volume. It is currently not 
used and always contains 0. 

n.VLEV 2 Bytes Volume Structure Level 

This word identifies the volume's structure level. 
Like the file structure level, this word 

identifies the version of Files-11 which created 
this volume and permits upwards compatibility of 
media as Files- 1 1 . evolves . The volume structure 
level is affected by all portions of the Files-11 
structure except the contents of the file header. 
This document describes Files-11 version 1; the 
only legal value for the structure level is 401 
octal. . ’ 

H.VNAM 12 Bytes Volume Name 

This area contains the volume label as an ASCII 
string. It is padded out to 12 bytes with nulls. 
The volume label is used to identify individual 
Files-11 volumes. 

4 Bytes Not Used 

H.VOWN 2 Bytes Volume Owner UIC 

This word contains the binary UIC of the owner of 
the volume. The format is the same as that of the 
file owner UIC stored in the file header. 

H.VPRO 2 Bytes Volume Protection Code 

This word contains the protection code for the 
entire volume. Its contents are coded in the same 
manner as the file protection code stored in the 
file header, and it is interpreted in the same way 
in conjunction with the volume owner UIC. All 
operations on all files on the volume must pass 
both the volume and the file protection check to 
be permitted. (Refer to the disjcussion on file 
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5.1.2.11 



5.1.2.12 



5.1.2.13 

5.1.2.14 



5.1.2.15 



5.1.2.16 
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protection in section 3. 4, 1.7). 

H.VCnA 2 Bytes Voiuae Characteristics 

This word contains bits which provide additional 
control over access to the volume. The following 
bits are defined: 

CH.NDC bet ii device control functions are not 
permitted on this volume. Device 
control functions are those which can 
threaten the integrity of the volume, 
such as direct reading and writing of- 
logical blocks, etc. 

CH.NAT Set if the volume may not be attached, 
i.e., reserved for the sols use by one 
task . 

H.FPRO 2 Bytes Default File Protection 

This word contains the file protection that will 
be assigned to all files created on this volume if 
no file protection is specified by the user. 

- 6 Bytes Not Used 

H.WISZ 1 Byte Default Window Size 

This byte contains the number of retrieval 
pointers that will be used for the "window” (in 
core file access data) when files are accessed on 
the volume, if not otherwise specified by the 
accessor. 

H.FIEX 1 Byte Default File Extend 

This byte contains the number of blocks that will 
be allocated to a file w h en a user extends the 
file and asks for the system default value for 
allocation . 

H.LRUC 1 Byte Directory Pre-access Limit 

This byte contains a count of the number of 
directories to be stored in the file system's 
directory access cache. More generally, it is an 
estimate of the number of concurrent users of the 
volume and its u_se may be generalized in the 
future. 
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5.1.2.17 

5.1.2.13 



5.1.2.19 



5 . 1 . 2.20 

5 . 1 . 2.21 



5 . 1 . 2.22 



5.1.2.23 



1 1 Bytes .Mot Used 
H.CKK1 2 Bytes First Checksus 

This word is an additive checksum of all entries 
preceding in the home block (i.e., all those 
listed above). It is computed by the same sort of 
algorithm as the file header checksum (see section 
3 .4 . 4 . 1 ) . 

H.VDAT 14 Bytes Volume Creation Date 

This area contains the date and time that the 
volume was initialized. It is in the format 
•♦DDMMMYYHHMMSS'' , followed followed by a single 
null. (The same format is used in the ident area 
of the file header, section 3.4.2). 

^ 393 Bytes Not Used 

This area is reserved for the relative volume 
table for volume sets. 

H.INDM 12 Bytes Volume Name 

This area ’ contains another copy of the ASCII 
volume label. It is padde.d out to 12 bytes with 
spaces. It is placed here in accordance with the 
proposed volume identification standard. 

a.INDO 12 Bytes Volume Owner 

This area contains an ASCII expansion of the 
volume owner UIC in the form "C pro j , prog] " . Both 
numbers are expressed in decimal and are padded to 
three digits with leading zeroes. The area is 
padded out to 12 bytes with trailing spaces. It 
is placed here in accordance with the proposed 
volume identification standard. 

H.INDF 12 Bytes Format Type 

This field contains the ASCII string ”DECFILE 1 i A " 
padded out to 1? bytes with spaces. It identifies 
the volume as being of Files-li format. It is 
placed here in accordance with the proposed volume 
identification standard. 



5.1.2.24 



2 Bytes Not Used 
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2.25 H.CHK2 2 Bytes Second Checksum 

This word is the last word of the home block. It 
contains an additive checksum of the preceding 255 
words of the home block, computed according to the 
algorithm listed in section 



( aJ 
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Index File Bitmap Size 
Index File 
Bitmap LBN 

Maximum Number of Files 
Storage Bitmap Cluster Factor 
Disk Device Type 
Volume Structure Level 



Volume Name 



(not used) 



Volume Owner UIC 



Volume Protection 



Volume Characteristics 



Default File Protection 



(not used) 



Def. File Extend 


Def. Window Size 




Directory Limit 
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H. IBSi 
H. IBLB 

H. FMAX 
H.SBCL 
H. DVTY 
H.VLEV 
a . VNAM 



H.VOWN 
a. VPRO 
a. VCBA 
B.FPRO 



a . wisz 

a . LRUC 
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(not used) 



First Checksum 



H . CHK1 
K. VDAT 



Volume Creation Date 



(not used) 



4 



H . INDN 



Volume Name 



Volume Owner 



H . INDO 
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Format Typa 



(not used) 



Second Checksum 



H . INDF 



K.CKK2 



5.1.3 Index File Bitmap 

• 

The -index file b i tmao is used to control the allocation 
of file numbers (and hence file headers). It is simply a 
bit string of length n, where n is the maximum number of 
files permitted on the volume (contained in offset H.FMAX.in 
the home block) . The bitmap spans over as many blocks as is 
necessary to hold it, i.e., max number of files divided by 
4096 and rounded up. The number of blocks in the bitmap is 
contained in offset H.IBSZ of the home block. 

The bits in the index file bitmap are numbered 
sequentially from 0 to n-1 in the obvious manner, i.e., from 
right to left in each byte, and in order of increasing byte 
address. Bit j is used to represent file number j+l : if 
the bit is 1, then that file number is in use; if the bit 
is 0, then that file number is not in use and may be 
assigned to a newly created'"'' file. 

The index file bitmap starts at virtual block 3 of the 
index file and continues through VBN 2+m, where m is the 
number of blocks in the bitmap. It is located at the 
logical block indicated by offset H.IBLB in the home block. 



5.1.4 File Headers 

The rest of the index file contains all the fils 
headers for the volume. The first 16 file headers (for file 
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nuabers 1 to 16) are logically contiguous, with the index 
file bitaap to facilitate their location; the rest nay be 
allocated wherever the file system sees fit. Thus the first 
16 file headers may be located from data in the home block 
(H.1B3Z and H.IBL3) while the rest must be located through 
the mapping data in the inde.x file header. The file header 
for file number n is located at virtual block 2+m+n (where m 
is the number of blocks in the. index file bitmap). 



5.2 Storage Bitmap File 

The storage bitmap file is File ID 2,2,0. It is listed 
in the MFD as BITMAP . SYS ; 1 . The storage bitmap is used to 
control the available space on a unit. It consists of a 
storage contro 1 block which contains summary information 
about the unit, and the bitmap itself which lists the 
availablilty of individual blocks. 



5.2.1 Storage Control Block 

Virtual block 1 of the storage bitmap is the storage 
control block. It contains summary information intended to 
optimize allocation of space on the unit. The following 
items are in the storage control, block; 

(3 bytes) Not used (zero) 

(1 byte) Number of storage bitmap blocks 

(2 bytes) Number of fr«.' blocks in 1st bitmap block 

(2 bytes) Free block pointer in 1st bitmap block 



(2 bytes). Number of free blocks in nth bitmap block 
(2 bytes) Free block pointer in nth bitmap block 
(4 bytes) Size of the unit in logical blocks 

Note: Current implementations of Files-11 do not correctly 

initialize the word pairs containing number of free blocks 
and free block pointer for each bitmap block, nor are these 
values maintained as space is allocated and freed on the 
unit. They are therefore best looked upon as 2n garbage 
words and should not be used by future implementations of 
Files-11 until the disk structure is formally updated. 



5.2.2 Storage Bitmap 

Virtual blocks 2 through n+l are the storage bitmap 
itself. It is best viewed as a bit string of length m, 
numbered from 0 to m- 1 , where m is the total number of 
logical blocks on the unit rounded up to the next multiple 
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of 4096. The bits are addressed in the usual aanner (packed 
right to left in sequentially numbered bytes) . Since each 
virtual block holds 4096 bits, n blocks, where n = m/409o, 
are used to hold the bitmap. Bit j of the bitmap represents 
logical block j of the volume; if the bit is set, the block 
is free; if clear, 'the block is allocated. Clearly the 
last k bits of the bitmap are always clear, where k is the 
difference between the true size of the volume and m, the 
length of the bitmap. 



5.3 Bad Block File- 

The bad block file is File ID 3,3,'0. It. is listed in 
the MFD as BADBLK . SYS ; 1 . The bad block file is simply a 
file containing all of the known bad blocks on the volume. 



5 . 3.1 Bad Block Descriptor 

Virtual block 1 of the bad block file is the bad block 
descriptor for the volume. It is always located on the last 
good block of the volume. This block may contain a listing 
of the bad blocks on the volume produced by a bad block scan 
program or diagnostic. The. format of the bad block data is 
identical to the map area of a file header, except that the 
first fo-ur entries (M.ESQN, H.ERVN, M-.EFNU, and H.EFSQ) are 
not present. • Thfe last word of the*block contains the usual 
additive checksum. (See section 3 • . 3 for a description of 
the map area.) This block is included in the bad block file 
to save the data it contains for future re- initialization of 
the volume. 



Bad Block Descriptor Layout 



LBN Field Size 1 Count Field Size 



Map Words Avail. I Map Words in Use 



Retrieval Pointers 



Block Checksum 




FILES -11 ON -DISK STRUCTURE 



PAGE 29 



5.4 Master File Directory 

The aaster file directory is File ID 4,4,0. It is 
listed in the MFD (itself) as 00000,0 . DIR ; 1 . The MFD is the 
root of tne volume's directory structure. It lists the five 
known files, plus whatever the user chooses to enter. In 
the two level UFD structure described in section 4.1.1, the 
MFD contains entries for all user file directories. 



5.5 
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file is 


File ID 5,5,0. 


It is 1 i s 


ted in 
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MFD 


as 


CORIMG 


.SYS; 1 . 


Its use is 


operating 


system 



dependent. In general, it provides a file of known File ID 
for the use of the operating system, for use as a swap area, 
for example, or as a monitor overlay area, etc. 

6.0 FCS File Structure 

File Control Services ( FCS ) is a user level interface 
to Files-11. Its principal feature is 'a record control 
facility that allows sequential processing of variable 
length records and sequential and random access to fixed 
length record files. FCS interfaces to the virtual block 
facility provided by tne basic Files-ll structure. 



6.1 FCS File Attributes 

FCS stores attribute information about the file in the 
file's user attribute area (H.UFAT - see section 3. 4. 1.9). 
It uses only the first 7 words; the rest are ignored by 
FCS, but are reserved by DEC (see Section 7.1 RMS FILS 
ATTRIBUTES). The following items are contained in the 
attribute area; they are identified by the usual symbolic 
offsets (relative to the start of the attribute area). The 
offsets may be defined in assembly language programs by 
calling and invoking the macro FD0FF$ DEF$L. Flag values 
and bits may be defined by calling and invoking the macro 
FCSBT$. These macros are in the system macro library of any 
operating system that supports Files-11. Alternatively, all 
these values are defined in the system object library of any 
system that supports Files-11, and may be obtained at link 
time. 

6.1.1 F.RTY? 1 Byte Record Type 

This byte identifies which type of records are 
contained in this file. The following three 
values are legal: 




CO 
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R.FIX Fixed length records. 

R.VAR Variable length records. 

R.SEQ Sequenced Variable Length records 

6.1. 2 F.RATT 1 Byte Record Attributes 

This byte contains record attribute bits that 
control the handling of records under various 
contexts. The following flag bits are defined: 

FD.FTN Use Fortran carriage control if set. 

The -first byte of each record is to be 
interpreted as a standard Fortran 
carriage control character when the 
record is copied to a carriage control 
device . 

FD.CR Use implied carriage control if set. 

When the file is copied to a carriage 
control device, each record is to be 
preceded by a line feed and followed by 
a carriage return. Note that the FD.FTN 
and FD.CR bits are mutually exclusive. 

FD.PRN Used to indicate, that . the two byte- 

sequence number field for R.SEQ record 
format is "to be interpreted as print 
control information (see Section 6 . 2 . 3 . 1 
for format of print information) . 

FD^BL.? Records do, not cross block boundaries if 
set. Generally, there will be dead 

space at the end of each block; how 

this is handled is explained in the 
description of record formats in section 
6 . 2 . 

F.RSIZ 2 Bytes Record Size 

In a fixed length record file, this word contains 
the size of the records in bytes.. In a variable 
or sequenced variable length record file, this 
word contains the size in bytes of the longest 
record in the file. 

6.1.4 F.HIBK 4 Bytes Highest VBN Allocated 

This 32 bit number is a count of the number of 
virtual blocks allocated to the file. Since this 
value is maintained by FCS, it is usually correct, 
but it is not guaranteed since FCS is a user level 
package . 




FILES-n Ol'i-DISK STRUCTURE 



PAGE 3' 



6.1.5 F.SFBK 4 Bytes Exid of File Block 

This 32 bit number is the VBM in which the end of 
file is located. Both F.HIBK and F.EFBK are 
stored with the high order half in the first two 
bytes, followed by the low order half. 

6.1.6 F.FF3Y 2 Bytes First Free Byte 

This word is a count of the nuaber of bytes in use 
in the virtual block containing the end of fils; 
i.e., it is the offset to the first byte of the 
file available fo_r appending. Note that an end of 
file that falls’ on a block boundary nay be 
represented in either of two ways. If the file 
contains precisely n blocks, F.EFBK o a y contain n 
and F.FFBY will contain 512, iLL F.SFBK may contain 
n+1 and F.FFBY will contain 0. 

6.1.7 S.FATT 14 Bytes Size of Attribute Block 

This symbol represents the total number of bytes 
in the FC3 file attribute block. 



6.1. A FCS File Attributes Layout 



F.RATT I Record Attr. i Record Type ! F.RTY? 

I I ! 

1 Record Size (Bytes) 1 F.RSIZ 

i Highest VBN ! F.HIBK 

I Allocated 1 

I End of File ! F.EFBK 

I VBN 1 

I First Free Byte ! F.FFBY 

1 ! S.FATT 



6.2 Record Structure 

This section describes how records are packed in the 
virtual blocks of a disk file. In general, FCS treats a 
disk file as a sequentially numbered array of bytes. 
Records are numbered consecutively starting with 1. 



X* 
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6.2.1 Fixed Length Records 

In a file consisting of fixed length records, the 
records are siaply packed end to end with no additional 
control information. if the . record length is odd, each 
record is padded with a single byte. The content of the pad 
byte is undefined. For direct access, the address of a 
record is computed as follows: 

Let: n = record number 

k = record size (in bytes) 
m s byte addres’s of record in file 
q s number of records per block 
j s VBN containing the start of the record 
i s byte offset within VEM j 

then h = ((k+l)/2)*2 (rounded up record length) 

ms ( n- 1 ) *h 

j s m/512+1 (truncated) 
ism mod 512 

The previous discussion assumes that records cross block 
boundaries (that is, FD.BLX is not set), If records do not 
cross block boundaries, they are limited to 512 bytes, and 
the following equations apply (the variables are defined as 
above): • 

h s ((k+l)/2)»2 (rounded up record length) 
q s 512/k (truncated) 
j s (n-1)/q+l (truncated) 
i s ( ( n- 1 ) mod q) *h 



6.2.2 Variable Length Records 

In a file consisting of variable length records, 
records may be up to 32767 bytes in length. Each record is 
preceded by a two byte binary count of the bytes in the 
record (the count does not include itself). For example, a 
null record is represented by a single zero word-. The byte 
count is always word aligned; i.e., if a record ends on an 
odd byte boundary, it is padded with a single byte. The 
content of the pad byte is undefined. 

If records do not cross block boundaries (FD.BLK is. set) , 
they are limited to a size of 510 bytes. A byte count of -1 
is used as a flag to signal that there are no more records 
in a particular block. The remainder of that block is then 
dead space and the next record in the file starts at the 
beginning of the next block. 
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0 . 2.1 Sequenced Variable Length Records . 



The format of a sequenced file is identical to a 
variable length record file except that a two byte sequence 
number field is located immediately after the byte count 
field of each record. This field contains a binary value 
which is usually interpreted as the line number of that 
record (see Section 6.1.2 FD.PHN and Section 6. 2. 3.1). The 
sequence number is not returned as part of the data when a 
record is read, but is available separately. Mote that the 
record byte count field. counts the sequence number field as 
wellasthedataoftherecord. 



6.2.5. 1 Format of Two Byte Print Control Field in R.SSQ 
Records 



If the FD.PRM bit is set in the record attribute then 
the two byte "sequence number" field is used to contain 
carriage control data for the record. Byte 0 is print 
control information to act upon before the record data is 
Output to a unit record device; byte i is print control 
information to act upon after the record data has been 
output to a unit record device. 



The format of each byte is as follows:- 

Bit? Bits 6-0 Meaning * 

20 No carriage control 

0 count(1-l27) "count" new lines (CR/LF) 

Bit 7 Bit 6 Bit 5 Bits 4-0 Meaning 



1 

1 

1 



0 0 
0 1 
1 0 



ASCII CO SET- 
ASCII Cl SET 
CODE (0-63) 



ASCII CHAR TO 
OUTPUT (CR.FF etc.) 
ASCII CHAR (8 BIT CODE) 
TO OUTPUT 

Device specific code 



1 



Reserved 



NOTE 

The print control field is not currently supported 
by FCS or RMS-1 1 . ■ 
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7.0 RECORD MANAGEMENT SERVICES (RMS) 



Record Management Services (RMS) is a user level 
interface to Files -11. It provides a flexible means of data 
storage, retrieval, and modification through a combination 
of file organization and record access modes. File 
organization is the structure of data within the virtual 
blocks of a Files-ll file, and record access mode is the 
manner in which storing and retrieving the data, in the file 
occurs . 

RMS supports/defines three file organizations which are: 

. Sequential - compatible with FCS fixed, variable, 
and sequenced variable record files (see Section 6) 

. Relative - RMS only 

. Indexed - RMS only 

RMS interfaces to the virtual block facility provided by the 
Files-11 structure. 



7.0.1 ' Data Formats and Representation 



RMS supports file organizations which require a more 
complex degree of structuring than that required by FCS. 
RMS also stores binary values in a different manner’ in 
general than Files-1i defines. For these reasons the data 
format and representations used by RMS are given in the 
following sections. 



7.0. 1.1 String Storage 



All strings are stored left justified. The left most 
character is in byte N and the right most character is in 
byte N+M-1 where M is the length of the string. 



7. 0.1. 2 String Character Code Set 



All string values are assumed to be in the 7-bit 
code set. 



ASCII 
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7.0. 1.3 String Collating Sequence 



The collating sequence used is the 7 -bit ASCII code set 
where NUL is the lowest valued character and DEL is the 
nighest valued characcer. 



NOTE 

The internal representation of ASCII characters on 
PDP-11 systems is-7-bit ASCII. The string compare 
routine of RMS-11 however, performs a full 8-bit 
unsigned compare per character. RMS does not 
perform any "clear bit 7" code on input or output 
operations. This allows the support of user binary 
byte strings, the KANA character set used in Japan, 
and' in the future 8-bit ASCII when defined, without 
RMS modifications since the true colating sequence 
is lowest character = 0 and highest character = 255. 



7 . 0.1. 4 Unsigned Binary Value Storage 



All unsigned binary values are stdred with the Leas 
Significant ^its (LSB) in'byte N and the Most Significan 
Bits (MSB) in byte N+M-1 where M is the length of the binary 
value . 

EXAMPLE; 2 byte unsigned binary value 



N 



N + 1 



LSB 



MSB 



7.0. 1.5 Signed Binary Value Storage 



All signed binary values a-re stored as unsigned binary 
values except that most significant bit (bit 7 of byte 
N+M-i) of the value is interpreted as the sign of the value. 
Negative numbers are stored as the two’s complement of the 
positive value. 



ct- Ct 
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# 

EXAMPLE: 2 .byte signed binary value 

N 

N + 1 



LSB 



S ! MSB 



7. 0.1. 6 Pointer Values 



All pointers are stored as unsigned binary, values. 
Pointers are stored variable length. The length of a 
pointer value is specified by the control bits associated 
with the pointer. The length requirement for a pointer is 
cete mined by the range of VBN values it falls in as 
follows: 

2 bytes start VBN 1 - 65,535 

3 bytes start VBN 55,536 - 16,777,215 

4 bytes start VBN 15,777,216 - 4,294,967,295 



7. 0.1. 7 Bucket Pointers 



A bucket pointer is a pointer value which specifies the 
start VBN of the bucket. The length of the bucket (number 
of VBN's in bucket) is interpreted in the context of its 
usage within the file, and is specified in the file’s prolog 
data. 



EXAMPLE: 2 byte bucket pointer 



LSB i N 



MSB I N+1 



7. 0.1. 6 Record Pointers 

Record pointers are composed of two fields, a one byte 
record ID field followed by a bucket pointer. The ID is 
used as a unique record identifier for records within a 
bucket. The records are tagged with their ID'S when stored 
in the bucket. 
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EXAMPLE: 3 byte record pointer 

N xSECORD ID 
N + 1 BUCKET POIxNTSR 
N + 2 



ID 



LSB 



MSB 



7. 0.1. 9 Packed Decimal Strings 

Packed decimal strings are from i to 16 bytes in 
length. The format is' as follows: 



7 4 2 0 



! di 


1 d2 


1 A 


1 d3 


1 d4 


1 A + 1 


• 

• 


1 di 


.1 sign 


i A+N-1 



where: 

d s digit in the range of 0 thru 9 (binary 
value ) 

sign is plus if value is 1Q, 12, 14, or 15 

sign is minus if value is 11 or 13 
N is length of strings in bytes 

i = (N-1)*2-*>1 and is an odd nu.Tiber in the ' range 
of 1 thru 31 

dl is most significant digit (may be a leading 
zero) 

di is least significant digit 



7.1 RMS FILE ATTIRiaUTES 
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RMS stores attribute infornation about the file in the 
file's user attribute area (H.UFAT - see Section 3. 4. 1.9). 
It uses the first ten (10) words; the rest are reserved by 
RMS. Tne following iteas are contained in the attribute 
area; they are identified by syabolic offsets into an RMS 
internal structure. The relative offset into the attribute 
area aay be calculated by subtracting F$F0RG froa the given- 
offset naae/value. The offset definitions aay be defined in 
assembly language programs by calling and invoking the macro 
IFaOF$ RMSSL. Flag values and bits may be defined by 
calling and invoking the FABS3T DFIN$L macro. These macros 
can be found in the RMSHAC.ML3 macro library on all PDP-11 
systems supporting RMS. 



7.1.1 F$F0RG 1 Byte Record Format and Fils Organization 

This byte identifies the file's ■ organization and 
which type of record format it contains. The 
record format is contained in bits 0 - 3. and the 
file's organization is contained in bits 4-7. 
The symbolic values are defined such that they aay 
be OR'ED to yield the contents of the F^FORG 
field . 

Record Formats: 

, FB$UDF Undefined record format (Block I/O only 
file) 

FB$FIX Fixed length records 
FB$VAR Variable length records 

FB$VFC Variable with Fixed Control (VFC) records 

(the FCS R.SEQ is a special case form of 
the record format i.e., the fixed control 
area is two bytes long and contains the 
records sequence number) 

FB5STM ASCII stream records. RMS-11 used only 
as a means for RSTS/E ASCII data 
interchange. Records are delimited by 
vertical form effecter characters (LF, 
VT , FF and CR/LF pairs). 

File Organizations: 

FB$S£Q Sequential File organization (FB$SSQ = 0 

to maintain compatibility with FCS) 

FB$RSL Relative File organization 




r wCj 
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FB$IDX Index File organization 

FB$HSH Hashed File organization (not implemented) 



7.1.2 F$SATT 1 Byte Record Attributes 

This byte contains record attributes bits that 
control the handling of records under various 
contexts. The following flag bits are defined: 

FB:jFTN See Section 6.1.2 FD..'TN 

FB$CR See Section 6.1.2 FD.CR 

FB$PRN See Section 6.1.2 FD.PRN and 6.2.3. i 

FB$BLX Record do not cross block boun-'l = e-i rcf 
the Sequential file organization if set. 
See Section 6.1.2 FD.BLX for more detail. 



7.1.3 F$RSI2 2 Bytes Record Size 

In file containing fixed ' length format records 
this ' word contains the size ' of ’the records in 
bytes. In Sequential files gontaining variable or 
variable with fixed control formatted records this 
field contains the size in bytes of the longest 
record in the file. This field is undefined for 
Relative and Indexed files containing variable or 
variable with fixed control format records. 



7.1.4 F$HVBN 4 Bytes Highest VBN Allocated 

RMS updates- this field whenever the file is opened 
for write access. For details on this field see 
Section 6.1.4 F.KIBX. 



7,. 1.5 F$HEOF 4 Bytes End of File Block 

This 32 bit number is the VBN in which the end of 
file is located for the Sequential file 
organization. Both FSHVBN and F$HEOF ■ are stored 
with the high order half in the first two bytes, 
followed by the low order half. -The low order 
half is symbolically referenced by F$LVBN and 
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FSLEOF respectively. These are the’ only tvo 
places that RMS stores block numbers in this 
manner (see Section 7.0.1), and is done so to 
maintain compatibility with FCS. The Relative and 
Index file does not use this field and its value 
is usually ' (but not guaranteed) either the 
contents of F$HVBN or the contents of F$HVSM plus 
one . 



7.1.6 F$FFBY 2 Bytes- First Free Byte 

This field is used for the Sequential file 
organization* as a count of the number of bytes in 
use in the virtual block containing the end of 
file. The Relative and Indexed file organization 
do not use this field and its value will be either 
0 or 512. For more details on this field see 
Section6.1.6F.FF3Y. 



7.1.7 F$BXS2 1 Byte Bucket Size 

This field contains the bucket size or maximum 
bucket size for the Relative and Indexed file 
organization respectively.. The bucket size is 
represented aa the number of virtual blocks it 
contains. Legal values are from i - 32. For 
compatibility with FCS a value of 0 is interpreted 
as 1 . 



7.1.8 F$HDSZ 1 Byte Fixed Header Size 

This field contains the number of bytes <i - 255) 

in the fixed control area when the file contains 
I Variable with Fixed Control format records. A 
value of 0 is interpreted as 2 so that 
compatibility with FCS'S Sequenced Variable length 
record format file (R.SEQ) is maintained. 



7.1.9 F5MRS 2 Bytes Maximum Record Size 

This field contains a user specified maximum 
record size limit in bytes, to be enforced on 
output operations. Files containing Fixed length 
format records have F$MRS set equal to F$HSIZ. 
For all other record formats F$MRS is set to the 
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user specified value given w.hen the file was 
created. A value of 0 is interpreted as no 
aaxiaua record size limit specified. 



7.1.10 F^DSQ 2 Bytes default Extend Quantity 

This field contains a user specified default file 
extend quantity to be used whenever RMS needs to 
extend the file. A value of 0 is interpreted as 
use the volumes default extend. 
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7.1. A RMS File Attributed Layout 



F4KDSZ 



! Record Attr, 
1 


1 File. Org./rsc fmt 1 

1 


1 Record Size (bytes) i 

! 1 


I Highest VBN 


1 

1 

1 


! Allocated 

1 


1 

1 

1 


i End Of- file 1 

) 1 


! VBN 


1 

1 

1 


1 First Free 


Byte- 1 


1 Fixed Ctr. Size 


1 Bucket Size ! 

1 


1 Maximum Record 


Size Limit ! 

1 


i Default Extend 


Quantity ! 



F$F0HG 

F$RSIZ 

FIHVBM 



F$HE0F 



F$FFBY 



f$b:<sz 

F$MR3 



F$DSQ 



To calculate the offset into the User Attributes area in the 
file header subtract F$FORG from all* symbolic offsets. 



7.2 Prologue Blocks 

The RHS Relative and Indexed file organizations use the 
first several virtual blocks of the file to contain 
additional file description data-. This area of the file is 
called the file prologue.- In the Relative fils 
organization, the prologue is exactly one block long; in 

the Indexed organization its length varies. The symbolic 
offset names, and flag values and bits used in the file 
prologue blocks and record formats may be obtained by 
calling and invoking the following macros from the 



RMSMAC.MLB macro 
RMS. 


library 


on all PDP-11 systems supporting 


ARD0F$ 


RMS$L 




BKTOF$ 


■ RMS$L 




KDXOF$ 


RMS$L 




KDX$BT 


DFIN$L 




XAB^gST 


DFIN$L 




BKT$BT 


DFIN$L 




The iast word 


of every 


prologue block contains the 


standard Files-1 1 


check sum 


(see Section 3. 4. 4.1). 







PAGE 
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7.2.1 Prologue Block 1 (V3N 1) 



Prologue Block 1 contains coamon data for both the 
Indexed and Relative files, and file organization dependent 
data. The major Indexed file dependent data is the primary 
key defi.nicion (the K$XXXX symbols). The major Relative 
file aependent data are the maximum record number, the 
adaress of the first data bucket, and the "real” End of Pile 
Block (last initialized, zeroed, VBN). The primary key 
definition offsets (K$XXXX) are used for all key definitions 
within the prologue of t.he index file and are relative to 
the start of each key descriptor. 



The key definitions supply all the information needed 
oy RMS to retrive, insert, update, and delete records for 
tne Indexed file organization. The basic data which are 
contained in a key definition are as follows: 

. Where the associated key field is positioned in the 
record, and how long it is. 

. The VBN address of the associated Root bucket. 

. Various key field options 



The key definitions are linked into a ch'ain by the V-BN 
address and byte offset within the prologue block for the 
next key definition. The Indexed file organization can be 
viewed as a multi-partitioned file. The first partition is 
the prologue, the second partition is the index associated 
with the primary key definition, and the third partition is 
the user data associated with the primary index. Every 
indexed organized file contains these three partitions. In 
addition when alternate keys are defined then two additional 
partitions per alternate key are created. The first 
partition is the index associated with the alternate key 
definitio'n, and the second partition is the RMS data 
associated with the index. The RMS data contain pointers 
into the user data partition for the records meeting the 
various key values. The index is structured as an n'ary 
tree where the nodes of the index are buckets. The index 
structure is the same for all key definitions. 



7. 2. 1.1 .X3NLVB 4 Bytes VBN for Next Key Descriptor 

This field contains the virtual block address in 
which the next key descriptor may be found. This 
field is only looked at. when the K$BNYT field 
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contains a 0. When X$NL'VB and K$NBYT = 0 the last 
key descriptor has been found. The least 
significant 16 bits of the VBN are stored in 
K^NLVB and the most significant 15 bits are stored 
in K$.NLV3 + 2 (K^v'iHVB) . 



7. 2. 1.2 K?NBYT 2 Bytes Byte Offset for Next Key Descriptor 

This'word field contains the byte offset relative 
to the beginning of the V3N contained in I<$NLVB 
for the next key descriptor in the chain of key 
descriptors. The first key descriptor contained 
in a VBN starts at byte offset 0, and the chain 
will thread through the current VBM before going 
to the next VBN. This means that the V3N will 
only change when K$NBYT contains a 0. 



7. 2. 1.5 X;$IAN 1 Byte Index Area Number 

This byte contains the number of the Allocation 
Area to use for the index buckets associated with 
this key starting at level_ 2 going up to and 
including the Root* bucket. 



7. 2. 1.4 S$LAM 1 Byte Lowest Level Index Area Number 

. This byte contains the number of the Allocation 
Area to use for Level 1 of the index buckets 
associated with this key (a value of 0 means use 
the contents of S$IAN). 



7. 2. 1.5 X$DAN 1 Byte Data Level Area Number 

This field contains the number of the Allocation 
Area to use for the data level (level 0) of the 
index buckets associated with this key descriptor. 



7. 2. 1.6 K^LVL 1 Byte Level of Root 

This field contains the level number of the Root 
bucket associated with this key descriptor. This 
field is nat supported by RMS-ll release one. 
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7. 2. 1.7 K$I5iCS 1 Byte Index Bucket Size. 

This field contains the 'oucket size in yBN’’S for 
ail index level (level i through the root level) 
huckets (1 - 32) for this key descriptor. 



7. 2. 1.3 K^DB.^S 1 Byte Bata Bucket Size 

This field contains the bucket size in VBN'S for 
all data level, (level 0) buckets (1 - 32) for this 
key descriptor. 



7. 2. 1.9 ?$D3XS 1 Byte Data Bucket Size 

This is a symbolic redefinition of K$DBKS for use 
by the Relative file organization. 



7.2.1.10 KSLVBN 4 Bytes Address of Root Bucket 

This field contains the bucket address of the Root 
bucket for the index, associated with this key 
descriptor. The 32 bit VBN is stored in the 
manner described in Section 7. 2.1.1. 



7.2.1.11 K$FLGS 1 Byte Key Descriptor Flags 

This field contains a bit vector for the various 
key options supported by RMS as follows: 

XBjDUP Duplicate key values allowed 

XB$CHG Key value may change on $UPDATE 

operation 

XB$NUL Null key character enabled (K$NULL) 

XB$INI Index must be initialized 

When the XB$INI bit is set the K$LVBN field 
contains the following: 

K$LVBN = C(K$DAN) 

K$LVEN+1 = C(K$IAN) 

K$LVBN+2 = C(K$LAN) 

K$LVBN+3 = 0 not used 
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• 

This information is used once only when the index 
for this key definition is created. Since the 
area number information is not normally stored in 
the in memory data base for an open indexed file 
the required area numbers to create the index are 
stored in the root bucket field for this once only 
operation. The area numbers are not needed in the 
in memory data base since on future bucket' 
allocation the area number stored in the bucket 
which is "splitting" is used as the area number to 
allocate the new bucket from (see section 
7 . 5 . 1 . 1 . 2 ) . 



7.2.1.12 Pi^FLGS 1 Byte Prologue Flags 

This field is a symbolic redefinition of the 
K^jFLGS field for use by the Relative fils 
organization. Bits defined for this field are: 



PR$N£X Error encounted extending Relative file 
no further extending is possible. 



•7.2.1.13 K'i$DTP 1 Byte Data Type for Kay 

• 

This field contains the data type of the key field 
within the user data records. The only legal 

value currently for RMS-1 i is XB$STG. The 

following data types are defined. 



XB$STG 

XB$IN2 

XB$BN2 

XB$IN4 

XB$BN4 

XBSPAC 



String data type (unsigned 8-bit bytes) 
Signed 15 bit integer (2-bytes) 

Unsigned 16 bit binary (2 bytes) 

Signed 31 hit integer (4-bytss) 

Unsigned 32 bit binary (4-bytes) 

Packed decimal (1-16 bytes) 



7.2.1.14 K$NS£G 1 Byte Number of Segments in Key 

This field contains the number of segments (1-3) 
that make up the definition of the logical key 
field. The XB$IN2, XB$3N2, XB$IN4, XB$BN4, and 
XB$PAC key field data types may only contain one 
( 1 ) segment . 



7.2.1.15 K$NULL 1 Byte "NULL" Character 




This field contains a user spscifisd character. 
If the key field within the data'record associated 
with this key descriptor contains only "null" 
characters the record will not be inserted into 
the associated Index. The "null" value for the 
XB$IN2, XB$3N2, XB5IM4, XB4BN4, and XB$?AC key 
field data types is defined as zero (0). This 
field is enabled by the XB3NUL bit in the X$FLQ3 
and is only valid for alternate keys. 



7.2.1.15 K$KYSZ 1 Byte Total Key Size 

This field contains the sum of all the key. segment 
sizes to yield the total size of the key field in 
bytes (1 - 255 ) . 



7.2.1.17 KSKSY 1 Byte Key of Reference 

This field contains the key of reference number (0 
- 254) for this key descriptor. Primary key = 0; 
alternate keys s 1 - 254. 



7.2.1,. 18' K§MINU 2 Bytes Minimum Record Length 

This field contains the minimum length record, in 
bytes to contain the complete key field. 



7. 2.1. IS K^IFIL 2 Bytes Index Fill Quantity 

This field contains the number of bytes to use for 
index level buckets (levels 1 - n) before a bucket 
split is considered when the user requests RMS to 
follow fill quantities. 



7.2.1.20 K$DFIL 2 Bytes Data Fill Quantity 

This field contains the number of bytes to use for 
user level buckets (level 0) before a bucket split 
is considered when the user requests RMS to follow 
fill quantities. 




FILES' 

7.2.1 

7.2.1 

7.2.1, 

7.2.1. 

7.2.1. 

7.2.1. 
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.21 -K^POS 16 Bytes Key Segment Offset Positions 

This is a set of eight (8) 2 byte fields 
(K$P0S0-K$P0S7) which contain the relative offset 
(0 - n) into the data record for each key segment. 



.22 K$SIZ 8 Bytes Key Segment Size 

This is a set of 8 i byte fields ( K$srZ0-K$SI27 ) 
which contain- the size in bytes for the key 
segmen't. 



23 K$KNM 32 Bytes Key Name 

This is a 32 byte string supplied by the user when 
the key was defined. If not suoplied will contain 
NULLS. 



24 K$LDVB 4 Bytes First Data Bucket 

This field contains the bucket address of the 
f.irst ' bucket at the' data level (level 0) 
associated with this key descriptor. This field 
is not supported by RMS-11 release 1 and contains 
a zero. 



25 14 Spare By t e s 



26 P$AVBN 1 Byte VBN of First Area-Descriptor 

This field contains the VBN (2 - 255) of the first 
Allocation Area descriptor block. Allocation Area 
descriptor blocks are virtually contiguous and are 
directly accessed by area number. See Section 

7.2.3. 



27 P$AMAX 1 Byte Maximum Number of Areas 

This field contains the maximum number of defined 
Allocation Area descriptors ( 1 - 255) for this 
file. Eight (8) Allocation Area descriptor can 




7.2.1.25 



7.2.1.29 



7.2.1.30 



7.2.1.31 



7.2.1.32 



fit in a virtual block sines each arsa descriptor 
is 64 bytes long. The file address of any Area 
descriptor may be calculated as follows: 



Let: 


a 


= 


area number (0 - 


254 ) 




V 




VBN address for 


a 




0 


= 


offset into v fo 


r a 


Then : 


V 


s 


a/3 ( truncated) 


+ c(P5AVEN) 




0 


s 


( a mod a ) *64 





P^DVBN 4 Eytes Address of First Data Bucket 

This field contains the 32 bit VBN of the first 
data bucket in a Relative file. 



?$LMRN 4 Bytes Haxiaua Record Muaber 

This field contains the ^ user specified aa:ciaua 
record nuaber which will be allowed on $?UT 
operations to the Relative file organization. If 
the user specifies 0 then this field will contain 
the aaximuB record nuaber possible ( 2 ** 31 - 1 ). 



P$L20F 4 Bytes EOF VBN 

This field contains the last initialized (i.e., 
zeroed) VBN (i.e., the EOF VBN) for the Relative 
file organzation. 



P$VERN 2 Bytes Prologue Version Nuaber 

This field contains a prologue version nubaer. 
The only legal value at this time is one (1). 



Reserved for Future Use 392 Bytes 



7.2.1.33 



Prologue Checksum 2 Bytes (see 7.2) 
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K^LAN 

K$LVL 

K$05KS 

?$DSKS 

K;>DTP 

KSNULL 

K$K£Y' 



Prologue Block 1 Layout 



VBN For Next Key 
Descriptor 



Offset To Next 


Key Descp. 


Level 1 Area t 


1 Index Area ^ 


Root Level 


1 Data Area # 


Data Bkts 


! Index Bkts 


Size 


! Size 


Root 


Bucket 


Pointer 


Data Type 


! Flags 


"NULL'' Character 


1 # of key segments 


Key Of Ref. 


I Total Key Size 



Minimum Record Length 



Index Fill Quantity 
Data Fill Quantity 

Key Field Segment 
Offset Positions 
(K$PQS0-K$P0S7) 



I 

I 



Key Field Segment Sizes 
(K$SIZ0-K$SIZ7) 

f 

I 



Key Name String 
(32 Bytes) 



First Data Bucket 



K$NLVB 

K$NBYT 

K$IAN 

K$DAN 

K$IBKS 

K$LVBN 

K$FLGS 

P$FLGS 

K$NSEG 

K$KYSZ 

K$MINL 

K$IFIL 

K ^ D F X L 

K$P0S 

K$SIZ 

K$KNM 



K$LDVB 
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? ^AMAX 



! Pointer j 

/ Spare(i4Bytes) / 

i I 

i 1 

I f 

1 Max Area it I V3N Of 1st Area j 

i i 

! Start VBN of 1st Data Bucket 1 

i (relative file only) i 

I I 

I Maximum Record 1 

I Number 1 

I Relative File EOF VBN 1 

I __ __ I 

I (Last Initialized VBN - Zeroed) ! 

} i 

I - - I 

I Prologue Version Number 1 

I I 

I I 

/ Spare (392 Bytes) / 

i t 

I r 

! Block Checksum i 

I Byte Offset 510 I 



P 



$AVBN 

P3DVBN 



P$LMRN 



PSLSOF 



P$V£RN 



7.2.2 Alternate Key Prologue Blocks 

Alternate key prologue blocks are chained together 
through the K$NLVB field of the key descriptors (see Section 
7. 2. 1.1). Five alternate key descriptors can fit in a VBN. 



7.2.3 Area Descriptor Prologue Blocks 

The Indexed file organization requires a method of 
allocating the virtual blocks of the file to the various 
usages within the file (e.g-., Index buckets and Data 
buckets). The structure which allows this virtual block 
allocation management is the Area Descriptor. The Indexed 
file supports multiple allocation areas to achieve the 
following user file design capabilities: 

1. Different bucket sizes between the index buckets 
and associated data buckets. 



2. 



Different index and data bucket sizes on a per key 
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basis . 

3. Allocation placensnt control for the various 
elements of the file. 



Sight area descriptor can be contained in a virtual 
block, and all the area descriptor prologue blocks are 
virtually contiguous (see Sections 7.2.1.26 and 7.2.1.27 for 
more details) . 



7.2.3. 1 Spare 1 Byte 



7. 2. 3. 2 A$FLG 1 byte Flags (not used) 



7.2.3. 3 A$AID 1 Byte Area Number (0 - 254) 

This byte contains the Area's number and is used 
as a redundancy check since all area descriptors 
are located at a fixed relative ^ position * to the 
start of the Area Descriptor pro*"logue blocks. 



7. 2. 3. 4 A$BKZ 1 Byte Bucket Size for Area 

This field contains the areas's bucket size in 
blocks (1 - 32) which is the granularity of 
allocation. 



7. 2. 3. 4 A$V0L 2 Byte Relative Volume Number 

This field contains the relative volume number for 
the last file extend for this area when placement 
control was requested. 



7. 2. 3. 5 A$ALN 1 Byte Extend Allocation Alignment 

This field contains the allocation alignment used 
for the last file extend for this area. 

Legal values for this field are: 




tA) 
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G 

XB$CYL 

XB^LBM 

XB;?V3N 

XB$H?I 



placeasnt control not requested 
cylinder alignment (not implemented), 
logical block alignment 
virtual block alignment 
allocate close to related file 
by FID (not implemented) 



.6 A^iAOP 1 Byte Alignment Options 

This field contains option bits to qua.lify the 
A$ALN field. Legal values are as follows: 

XB$HRD Alignment is absolute and fail if not 
available (note: illegal for XB5VBM or 

XB$R?I alignment) . 

XB$CTG Allocation is to be contiguous. 



7. 2. 3-7 ■ A^AVL 4 Bytes Available (Returned) Buckets 

This field contains the 32 bit VBN of the first 
available bucket in a chain (linked through the 
first 4 bytes of t,he bucket) of buckets. Thi.s 
chain of buckets would be the result of returning 
buckets back to the area. • The returning of 
buckets is not currently supported by RMS so that 
the only legal value for this field is zero (0). 



7 . 2 . 3 • *3 A$CVB 4 Bytes Start VBN for Current Extent 

This field contains the 32 bit start VBN for the 
current extent. The current extent is the extent 
from which buckets will be allocated. 



7. 2. 3-9 A$CNB 4 Bytes Number of blocks in Current Extent 

This field contains the number of blocks that were 
allocated to this current extent. The combination 
of A$CVB and A$CNB describes in virtual block 
terms the result of the file extend operation for 
the current extent. 



7.2.3»''0 A$NUS 4 Bytes N urn ber of blocks used 
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7.2.3. 12 

7.2.3.13 

7.2.3. 14 

7.2.3.15 

7.2.3.16 



This field contains the n us her of blocks that have 
been allocatedfros the current extent. 



ASNV3 4 Bytes Next VBN to Use 

This field contains the 32 bit VBN to use for the 
start VB'N of the next bucket allocated fron the 
current extent. 



A$NXT 4 Bytes Start VBN for Next Extent 

This field contains the 32 bit start VBN for the 
next extent. When the current extent is used up 
the next extent is made the current extent and 'the 
next extent description is zeroed. The area can 
only be extended when the next extent description 
is zero. 



ASXBY 4 Bytes Number of blocks in Next Extent 

This field contains' the number of blocks that wer5 
allocated to- this next extent. Thie- combination 
of A^NXT and A$XBY describes in virtual block 
terms the result of the file extend operation for 
the next extent. 



A$DEQ 2 Bytes Default Extend Quantity 

This field contains the user specified default 
file extend quantity to be used whenever the area 
is to be extended by RMS. A value of 0 means use 
the file's DEQ. However, in 'no case will less 
than one bucket size for this area be requested. 



Reserved 2 Bytes 



A$L0C 4 Bytes Start LBN on Volume 

This field contains the start logical block number 
for the last extent performed for this area. 
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7. 2. 3.17 A$RFI 6 Sytes Related File ID 

This field contain the FID of a related file for 
the X35RFI allocation alignment (A$ALN) (not 
implemented) 



. 1 d Spares 1 2 Bytes 



7 . 2 . 3.19 A$CRC 2 Bytes Checksum 

This field is a dummy field to pad out the area 
decriptor to 64 bytes. This also allows the 
standard Files-1 1 checksum to be stored in the 
last word of the Area Descriptor Prologue block. 




PAGE 
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7.2. 3-A Area Descriptor Layout 



A^FLG 

A^BKZ 

A^AOP 



I Flags I Spare 


1 

1 

1 




i Bucket Size I Area Number 


1 

i 


A$AID 


! Relative Volume Number 


1 

J 

1 


A$V0L 


I Align Options i Alloc. Align. 


t 

1 

1 


ASALN 


I Available Bucket 

I List 


1 

1 

I 

1 


A$AVL 


i Start VBN For 

I Current Extent 


1 

1 

1 

1 

1 


A$CVB 


! Number Of VBN’s In 

I Current Extent 


1 

1 

1 

1 

1 


A$CNB 


I Number Of VBN's Used 
I In Current Extent 


1 

1 

1 

1 

\ 


A$NUS 


I Next VBN To Use For 
I Current Extent 


1 

1 

1 

1 

f 


A4NVB 


I Start VBN For 

i Next Extent 


1 

1 

1 

^ 1 


A$NXT 


I Number Of VBN’s In 
I Next Extend 


f 

1 

1 

1 

^ 1 


A$XBY 


I Default Extend Quantity 


1 

1 

^ 1 


A$DEQ 


i Spare 


1 

1 

^ 1 




! Start LBN For Last 

! Extend For This Area 


I 

1 

1 

1 

^ 1 


A$L0C 


! File ID For 

I Related File For 

I File Extends 


1 

1 

1 

1 

1 

1 

^ 1 


A$HFI 


! Spares 

! (12 Bytes) 


1 

1 

1 

1 

1 

1 

1 

1 

! 

1 

I 

1 

\ 




1 Dummy Field To Allow Block Checksum 


1 

1 


A$CRC 




u H 0 I 
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7.3 Sequential File Format 

The RMS Sequential file is compatible with the FCS 
Fixed and Variable length record files. Please refer to 
Section 6.2 through 6.2.3. The R.MS variable with Fix 
Control record format is a generalization of the Sequenced 
Varialbe Length 'Records of FCS (Section 6.2.3) in' that the 
fixed control area (always 2 bytes for FCS) can be varied 
bstweenito255bytes. 



7.4 Relative File Format 

The Relative file currently uses- virtual block one (1) 
for its prologue, and starts its data buckets at virtual 
block 2. Records are stored in fixed length cells within 
unformated buckets (no overhead bytes in bucket) starting at 
byte 0 and packed end 'to end (i.e., byte aligned). The 
virtual blocks within the relative file must be initialized 
(zeroed) when they are allocated to the file to support 
deleted record control. 



7.4.1 Relative File Record Formats 

Reco.rds are stored in fixed length cells; The first 
byte of each cell is a record control byte used to provide 
deleted record control. The following bits are defined: 

DC$DEL record has been deleted 
DCSREC record exists 

A value of 0 indicates the cell has never contained a 
record. 



The relative file supports variable and variable with 
fixed control length record up to the required user 
specified Maximum Record Size (MRS). In these cases the 
record control byte is followed with a two byte binary count 
of the bytes in the record (the count does not include 
itself). If the cell size does not evenly divide the^bucket 
size then the remaining space in the bucket is dead* space 
and the next record in the file will be stored in the first 
ceil of the- next bucket. In other words records never span 
bucket boundaries. 
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7.4. 1A Fixed Length Records 



! Ctrl i data (mrs bytes) 1 



cell size = MR3+1 



7. 4. 1.3 Variable Length Records 



I Ctrl I size ! data (size bytes) 1 



cell size s MflS+3 



7.4.1.C Variable With Fixed Control Records 



1 Ctrl 1 size 1 fixed i data (size-fixed Ctrl bytes) 1 



cell size s MR.S+FIXED CTRL _ SIZE’+S . 



7.5 Indexed File Format 

The Indexed File uses virtual blocks i , 2 and if 

necessary up to and including 84 as a maximum for its 
prologue. The current implementation on the PDP-11 will 
result in a prologue of the following forms: 

Single Key 



VBN 1 



PRIMARY KEY 
Description 



P$-AMAX ! P$AVBN 



1 < — 

I 

I 



VBN 2 



Area Descriptors 




G - D 1 5 K 



r a u i O-i 



(UpTo3}For 
single key 4 is all that 
can be used 




Index and Data 
Buckets 



Multiple Key 



V S M 1 


Primary Key 


« • 




Descriptor 


1 

1 

1 




P5AMAX 1 P5AVBN 


\ 

\ 

1 

1 

1 

1 

1 

1 

1 


— — , 

1 

1 

1 


• 

<M 

cq 

> 


4» 1 

J 


1 

<- — 


' 


Up To 5 Key 




■ 


Descriptors 




. 


Key 5 Descriptor 


1 



If more than 5 alternate keys 




KEY DESCRIPTORS 
ETC 



VBN P^AVEN 



Area Descriptors 
8 Per Slock 
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index and data bucket space starts at: 
( (PSAMAX/6 (TRUNCATED) )+?$AVBN) 



Records are stored in formatted buckets (bucke 
overhead oytes) and are packed end to end (i. 
aligned) . The Bucket format and the various record 
are given in the following sections. 



t s have 
e . , byte 
formats 




r" A u 
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7.5.0. Index Structure 

« 

The Index is structured as a balanced tree. The nodes 
in the tree are buckets, ana the nodes are serially 
searched. The Index node contains index records as 
specified in Section 7. 5. 2.1. 

The bucket size is constant for index nodes, but may be 
different than the Data buckets. The Data buckets are all 
the sane size. 

Each level of the incex is horizontaly linked via the 
Next bucket pointers. The horizontal linking is circular 
with the last bucket (noted by BC$LBK) pointing back to the 
first bucket. . The Data buckets for an Index may be viewed 
as the data level (set) of the index and are linked in the 
same manner as buckets in any other level of the Index, 
figure 7-2 shows the structure cf the Index. 

The key value associated with index records (see 
Sectic.”! 7. 5. 2.1) is the highest or highest possible key 
value in the bucket pcinted to by the bucket pointer in the 
record . 

The basic search rule for. an index search is to follow 
the first path for which the search key is equal to or less 
than the key value sfored in the index record. 



7.5.0. 1 Primary Key Index Structure 

The primary key index for a file is structured as 
seated in Section 7.5.0 above where the data level is 
composed of buckets which contain the User's data records. 
The data buckets may also contain RRV records. See Section 

7. 5. 0. 3 and 7. 5. 2. 3 for details on REV records. 



7. 5. 0.2 Alternate Key Index Structure 

An alternate key index for a file is structured as 
stated in Section 7.5.0 above where the data level is 
composed of ouckets which contain pointer array records as 
specified in Section 7. 5. 2. 4. Therefore the indices within 
the Indexed File Organization have the same structure, where 
only the interpretation of the records within the data level 
of an index is different. 



7. 5. 0.3 Record Reference Vector (RRV) 




FILES-11 0d-DI3S STRUCTURE 



PAGE 62 



when a record is inserted in an Indexed file the record 
is assigned a reference vector address and this address is 
stored in the cata record in the record pointer field (see 
Section 7. 5. 2. 2). This address is the initial address of 
tne record itself. Whenever the record is noved the 
record's reference vector record is updated with its new 
address. The record, in turn, points back to its reference 
vector so that it can be updated if the record is aoved 
again. The reference vector record is created when the 
record is moved for the first time. Using this technique 
the worst case indirec tion .for a record is kept at one, .and 
we can always find the record via its reference vector 
address. 

The record pointers used within the Indexed file 
organization, and the RFA (Record's File Address) returned 
to the user in the RFA field of tire RAB are always the 
record’s reference vector address. 

The space required for RflV^ pointers in the data records 
of a file is required .to insure RFA addressing and alternate 
keys. The RRV records are stored at the and of the data 
records in the user data buckets. The use of RRV's and 
seconaary indices is graphically shown in Figure 7-3. 
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7.5.1 Bucket Format 

The Indexed organization uses a foraatted bucket as its 
priaary unit of seondary storage. A bucket is coapcsed of 
some nua'oer of virtual blocks in the range of 1-32 and has a 
header starting' at byte one of the bucket. 

The Bucket is conposed of three logical areas, a Header 
area, a Record storage area and a Free space area. 

Each of these areas will be described in the sections 
that follow. 



7 . 5 . 1 . 1 Header Area 

Tne bucket header area is composed of a HAS data 
section, a bucket storage control section, and a 
structure link section. The size of the bucket 
header is 14 bytes (S$BHD). 



7. 5. 1.1.1 B$CHK 1 Byte Check Byte 

TiiiS'is a one byte check* character. Whenever a 
*oucket is written the value in the check byte is 
changed and copied into the last byte of the 
bucket. Whenever a bucket is read the check byte 
is compared to the copy for equality. By this 
technique hardware failures during transfer are 
detectable (i.e., the BUS breaks etc.). 



7. 5. 1.1. 2 B$TAA 1 Byte This Allocation Area 

This field contains the allocation area number 
that this bucket was allocated from. 



7. 5. 1.1. 3 B$ADR 2 Bytes Bucket Address Sample 

This is a sample of the bucket's start V3N 
address, and is composed of the low order i6 bits 
of that address. This field is written upon 
bucket formatting, and is checked whenever the 
bucket is read into main memory. 
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7. 5. 1.1. 4 B$NBY 2 Bytes Next Available Byte 

This field contains the byte address relative to 
the start of the bucket of the first free byte in 
the Free Storage Area of the bucket. 



7. 5. 1.1. 5 3$iilD 1 Byte Next Available ID 

This field contains the ID number to use for the 
next record placed in the bucket. 



7. 5. 1.1. 6 B5LID 1 Byte Last Available ID 

This fis.ld contains the ID number of the last ID 
in the contiguous range of ID’s specified by the 
contents of BSNI'D and B$LID. When the oontents of 
B$NID are greater than the contents of S$LID or is 
zero then there is no "next" available ID. When 
this condition oocurs the bucket is scanned to 
find the largest contiguous range of unused ID's 
and B$NID and B$LID are updated to describe that 
range . 



7. 5. 1.1. 7 B5NBX 4 Bytes Next Bucket Pointer 

This field contains the start VBN of the next 
bucket at this level of the index or data 
partition for the Indexed file organization. This 
pointer always points to a bucket of the same 
size. 



7. 5. 1.1. 8 B$LSV 1 Byte Level Number for Bucket 

This field contains the level number relative to 
the data level for this bucket, in the index. The 
Data level buckets contain a 0, the lowest- level 
buckets of the index contain a 1 , the next level 
buckets going towards the root contain a 2 etc. 




L>) 
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NOTE 

"Data buckets" refer to the buckets which 
contain the data records associated with 
the index. For che primary index these 
are the user data records, and for the 
alternate index these are system data 
records which contain an array of pointers 
to user data records. 



7 . 5 . 1 . 1 . 9 B$3CB 1 Byte Control Bits 

This is a bit encoded byte field and is used in 
the processing of a bucket. The following bits 
are defined for the indexed file organization: 

3C$LBK - last bucket in level 
BC$ROT - root bucket of index 



7. 5. 1.2 Record Storage Area 

The record storage area starts at the first byte 
after th'? bucket header area, and ends at the byte 
address stored in B$1IBY minus one. The record 
structures in buckets vary with the use of the 
bucket. Section 7.5.2 specifies the various 
record structures used. 



Free Storage Area 

The free storage area starts at the byte address 
stored in B$NEY and up to the check byte copy in 
the bucket. Any and all free storage statistics 
refer to this contiguous free storage area. 
However it is possible due to "fast" record 
deletions to have "free" space within the record 
storage area of the bucket. The reclaiming of 
this space is done on an as needed basis. 



7.5. 1.4 S$BHD 14 Bytes Size of Header Area 

This symbol represents the size of the bucket 
header area. 
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7 . 5 . 1 . A Bucket Format Layout 



B;$TAA 


1 This 


Area 


1 Check 


Byte 1 

1 


B$CHK 




1 — 

1 

1 

1 


bucke' 


Address 


Sample 1 

1 


B$ADH 




1 

1 

1 


Next Available 


Byte 1 

1 


B$NBT 


B$LID 


1 Last 
1 


ID 


i Next id 


\ 

1 

! 


■ a$NiD 




1 next Bucket Pointer 


\ 

1 


B$NBK 




1 

1 

1 


(Start VSN) • 


1 

1 

1 




B43CB 


1 — 
1 BCB 




! Level' 


J 

1 


B$LEV 




t 

I — — — — — — 






\ 


S5BHD 



Record Storage 
Area 



Free Space 
Area 



Check Byte Copy ! 



PAGE 6 



Bytes 



C( B$NBT) 
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7.5.2 Record Structures 



The 

Inaexed 



following record structures apply to the 
fils organization. 



7.5.2. 1 Index bucket record 



IRCS 



PS 



Bucket 

Pointer 



Key Value 



1 Byte 



n Bytes 



31 Bytes 



I R C B c 0 n t .a i n ? I r. ’i e x R e c r 'i C o n v ■- c 1 R 1 t 5 . 




.I;, the pointer size as follows: 

0=2 byte bucket pointer 
1 = 3 byte bucket pointer 
2=4 byte bucket pointer 
3 s undefined 
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7. 5-2. 2 General Data Bucket Record 



1 DRCB i PS 
1 


i 1 
1 


Byte 


i ID 

1 


1 

i 1 
1 


Byte 


i Record 

1 Pointer 
1 


1 N 
1 
t 
1 


Bytes Optional 


1 Size 

1 


1 

1 No 
1 


Size If Fixed Length Data 


1 

1 Data 

1 
1 


1 M 


Bytes 

= Size Or Fixed Length If 



DRCS contains Data Record Control Bits 



The following bits are defined in the DRCB byte: 



DC$DEL 



DCSRRV 
DC$NPS • 



Record deleted, or pointer to deleted 
record. 

Record reference vector record. . 

No pointer size field p.resent (qualifies 
PS-) 



DC$KDL Pointer to record for this key no longer 

applies $UPDATE changed the key, but 
record exists; note. ID will be zeroed 
on all systems starting with Release i 
on RSX-11M V3. 

DC$NCP Do not compress this deleted record. 



PS is the pointer size for the Record pointer as 
follows; 

0 s 3 byte record pointer 
1=4 byte record pointer 

2 = 5 byte record pointer 

3 = undefined 
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7. 5. 2. 3 HRV Records 

Record Reference Vector (RHV) records are records which 
point to the record associated with the reference vector. 
Tney function as "forwarding addresses" for the actual 
records when they are aoved. 

Tne foraat is as follows: 



DRCB 1 ?S 



ID 



Record 

Pointer 



where the DC$RRV bit is set in the DRCB field. 



7. 5. 2. 3.1 DELETED. RHV RECORDS 

The RRV record for a deleted record can be as small as 
the first two bytes of the RRV record. In this case the 
following DRCB bits are set: 

% * . 

• dC$rrv ■ • 

DC$NPS 

dcsdel 
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7. 5. 2. 4 Secondary (or alternate) Index Data Record (SIDR) 
for which duplicate keys are allowed 

The data records associated with an alternate index are 
pointer arrays to the users data records. The fcraat of the 
record is as follows: 





1 

1 


DRCB ! PS ! 


1 


Byte 




Data Record 


1 


ID i 


1 


Byte 






1 

1 


Duplicate Count ! 


4 


Bytes 


(DC$NP3=0 ) 


Overhead 


1 

1 


Size 1 


2 


Bytes 






1 

1 


Key Value 1 


M 


Bytes 




Data 

on 

Record 


1 

1 

1 

1 


SIDR Record 1 

Pointer iri 1 


X 


Byte 


Pointer 

Array 


1 

1 

1 

1 


SIDR Record 1 

Pointer?; 2 1 


Y 


■ Bytes 


record 




1 

1 

1 

1 

1 

1 


1 

• 1 

• 1 

1 

• t 










1 

1 

1 

1 


SIDR Record 1 

Pointer i^K 1 


Z 


Bytes 





Fields within the pointer array record 



PS . This field contains the size of the 

duplicate count field as follows 

0=3 bytes 

1 s 4 bytes »»TKIS IS THE ONLY VALUE 
USED** 

2 s 5 bytes 

3 = undefined 

DRCB Bits used for pointer array records 

NC$NPS If this bit is set then there 
is no duplicate count field. 
This is used for ail array 
continuations records, since 
the count applies to the total 
array. 




7. 5. 2. 5 Secondary (alternate) Index Data Record - No 
Duplicates 

The data records associated with an alternate index for 
wnich duplicate key values are not allowed is shown in 
S-otion 7. 5. 2. 4 except that the duplicate count field is 
omitted (DCpN?S=i) and there is only one SIDH Record 
Pointer. When a record is deleted the Mo Duplicates SIDH 
record is compressed out of the secondary index's data 
bucket at the time of the delete. 



7. 5. 2. 6 SIDH Record Pointers 

The format of the record pointers used in Secondary 
Index Data Records is as follows: 



Overhead 


1 DRCB ! PS ! 


1 Byte 


Record 


1 Record j 


N Bytes 


Pointer 
3-5 bytes 


1 Pointer I 

i t 

i 1 


' 


DHCB bits 


used for SIDR 


record pointers 



DC$KDL . 


Pointer has been, deleted' due 


to 


key 




change on a $UPDATE operation. 


In 


this 




case the ID portion of the 
pointer will be zero. 


re 


cord 


0 C $ D £ L 


Record associated with this point 
been deleted. 


er 


ha s 
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Figure 7-2 
Index Structure 
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NOTES : 

Ail buckets in a level are linked horizontally froa left to 
right via ne:ct bucket pointers (‘see Section 7 . 5 . *5 . ^ . 7 ) • 
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Figure 7-3 




